Product edition systems are known to include Computer-Aided Design or CAD, which relates to software solutions for authoring product design. A number of product and programs are offered on the market for the design of objects (or parts) or assemblies of objects, forming a product, such as the one provided by Dassault Systemes under the trademark CATIA.
Many products conceived today such as aircrafts or satellites are achieving a high level of complexity. It is usual that several teams of engineers work separately on the design of different components composing a product. The product is divided into a plurality of components and sub-components. Coordinating the work of dozens or possibly hundreds of workers is difficult. In order to manage this complexity, a product edition system can be used.
A well known system engineering approach defined by the International Council of Systems Engineering (INCOSE) defines four design stages namely R for Requirements, F for functional, L for Logical and P for Physical. The said design stages are represented on FIG. 1 and they can be implemented into a product edition system.
The requirement stage 100 leads to a structured definition of all the needs that the product must fulfil and a definition of the rules and regulations that should be respected.
The functional stage 101 leads to a structured definition of the services provided by the product in order to answer to its requirements. In other words, the aim of the functional stage is to define the system functions that will address the requirements.
The logical stage 102 aims at defining the logical architecture of the product through a structure of logical components. In other words, the functions are distributed on different logical components within different sub-systems.
Finally, the physical stage 103 provides the architecture of the product, that is to say the geometry of the logical components and how they fit together in a digital model of the physical product. This approach is often designated by the acronym RFLP.
Additionally, implement relations 104, 105, 106, 107, 108 can be created between different components belonging to different RFLP partitions 100, 101, 102, 103 in order to capture why an entity has been added to the definition.
For example, if a function is added in the functional stage to fulfil a given requirement, an architect will create an implement relation between the two components, that is to say between the function and the requirement. Implement relations can be typically set up between Requirements and Functions stages, Functions and Logical stages, Logical components and Physical stages. It is also possible to directly link a requirement to a logical component or to a physical component for some specific requirements that can not be translated into a functionality of the product. This is usually the case for requirements linked to a physical characteristic of the product to design such as the weight or the colour.
The components and sub-components that are designed and developed in one of the design stages are usually represented using a tree, the said tree being generally directed and acyclic.
A simple example is illustrated on FIG. 2. Two trees 200, 201 are represented. For a given product, the first tree 200 comprises the components associated to the functional stage and the second tree 201 comprises the components associated to the logical stage.
The trees have a hierarchical structure. The components of the first tree 200 are organized into four hierarchical levels 202, 203, 204, 205. The first level 202, which is the highest one comprises a single component A. The second level 203 comprises two components B and C. The third level 204 comprises four components D, E, F and I. The fourth level 205 is the lowest level of the first tree 200 and comprises two components G and H. Thanks to this hierarchical structure and with the use of hierarchical links, it is possible to introduce the notion of sub-components. For example, components G and H are seen as sub-components of component F because of a hierarchical link 210.
Regarding the second tree 201, the components are also organized into four hierarchical levels 206, 207, 208, 209. The first level 206 comprises one component 1 and is considered as the highest level. The second level 207 comprises two components 2 and 5. The third level 204 comprises five components 3, 4, 6, 9 and 10 and is considered as the lowest level of this tree. The fourth level 209 comprises two components 7 and 8.
As already introduced, in order to take into account progress in the product design, it is possible for a system designer to use implement relations 211, 212, 213, 214. Those relations are called implementation links in the sequel. In FIG. 2, the logical component 3 implements the functional component B, thus an implementation link 211 has been set up between the said components. For similar reasons, an implementation link 212 has been set up between components 4 and D, an implementation link 213 has been set up between components 6 and F and an implementation link 214 has been set up between components 10 and I.
The system designers and project leaders may have to check regularly the status of the project. It is important, for example, to check what part of the functional design of the product has been implemented or not into the logical architecture at a given point in time. For that purpose, a comparison between components of the trees representing the functional and the logical stages can be performed in order to verify whether all components are implemented or if a given component has been implemented in time.
For a simple system to design, this comparison can be done manually because of a limited number of components. However, for the design of a complex system, each tree comprises a large number of components. In that case, the comparison between trees can not be done manually and the use of a tool that performs this comparison automatically is required.
A well-known technique that can be used is to compare flat lists of components. The result of this comparison can be presented as a matrix, the elements of this matrix being used to monitor the progress of the product design.
For that purpose, a first approach is based on checking automatically leaf nodes traceability. In the sequel, a leaf node refers to a component without children. As an illustration, the first tree 200 presented on FIG. 2 comprises six leaf nodes B, D, E, G, H and I.
FIG. 3 presents two examples of traceability matrices obtained based on leaf nodes analysis. A first matrix 300 comprises a column 302 with one element per leaf node. For each leaf node associated with an implementation link, the identifier of a corresponding component in the second tree is memorized. In this example, identifiers of the components belonging to the first tree are letters and identifiers of the components belonging to the second tree are numbers. Considering this example, there is a implementation link between components B and 3, D and 4, 1 and 10. An other way to memorize this information is to use a matrix 301 that comprises a sub-matrix 303 with a number of column corresponding to the number of leaf nodes that belongs to the second tree 201 and a number of lines corresponding to the number of leaf nodes that belong to the first tree 200. The elements of the matrix that correspond to an existing implementation link are set up to a predetermined value while other elements are set up to an other predetermined value. For example, a binary digit can be used as an element of this matrix. It appears that the two aforementioned matrix are equivalent in term of content.
A second existing approach is based on a checking of every components belonging to the trees to compare. FIG. 4 presents two examples of traceability matrices obtained comparing every component of the trees. A first matrix 400 comprises a column 402 with one element for each component of the first tree 200. A second matrix comprises a sub-matrix 303 with a number of column equal to the number of components belonging to the second tree 201 and a number of lines corresponding to the number of components belonging to the first tree 200.
The major concern of these approaches is that the hierarchical structure of the trees is not taken into account. In particular, they do not handle properly cases where relations are created between intermediate components. For example, if there is an implementation link between 6 and F, this means that components implementing G and H have been implemented in the second tree. Unfortunately, this information can not be obtained directly from reading the matrix described above. Additionally if H is not implemented and that component 7 implements component G, the information that component F has been partially implemented is not available directly.
In the approach based on leaf nodes traceability, a component with one or more child is not considered.
Concerning the approach were all components are listed flatly, these links on intermediate nodes are incorrectly managed during global coverage computation as the hierarchy is not considered.
Therefore, traceability tools that use those approaches are inadequate to monitor accurately the advancement of a system design. This is particularly critical in a scenario involving OEM suppliers (Original Equipment Manufacturer) and where the said suppliers are responsible of the design of a given component. A difficult situation to manage in term of traceability is when an OEM supplier is selected to provide a set of logical components corresponding to a functional component, for example, when an OEM supplier has to design component 6 that implements component F.